C/C++ Users Group Library 1996 July

home *** CD-ROM | disk | FTP | other *** search

/ C/C++ Users Group Library 1996 July / C-C++ Users Group Library July 1996.iso / utils / unix / unzip-5.12 / INSTALL < prev next >

Wrap

Text File | 1994-08-22 | 19.6 KB | 382 lines

__________________________________________________________________________ This is the Info-ZIP file INSTALL (for UnZip), last updated 23 Aug 94. __________________________________________________________________________ Yes, this is a rather long file, but don't be intimidated: much of its length is due to coverage of multiple operating systems and of optional customization features, large portions of which may be skipped. --GRR __________________________________________________________________________ To compile UnZip, UnZipSFX and/or fUnZip: ========================================= (1) Unpack *.c and *.h (the actual source files), preserving the directory structure (e.g., ./unix/unix.c). The sole exception is TOPS-20, where tops20/* should be unpacked into the current directory, but TOPS-20 is no longer fully supported in this version. If you wish to compile with decryption enabled, you must get the zcrypt package (see "Where"). Unpack crypt.c and crypt.h from the zcrypt ar- chive, overwriting the dummy versions supplied with UnZip. If you don't have any sort of unzipper available, you'll have to compile the non- crypt version first and use that to unpack the full crypt sources, then recompile. (The included zipcloak.c file is for use only with the Zip 2.0.x sources, so don't bother unpacking it.) (2) Choose the appropriate makefile based on the description in the Con- tents file for your OS (that is, there's only one for Unix or OS/2, but MS-DOS and several other OSes have several, depending on the compiler). Copy it into the current directory and rename if necessary or desired. (Some makefiles can be invoked in place; see (5) below.) Special point of confusion: some MS-DOS targets are in non-MSDOS makefiles. In particular, for DOS emx+gcc use the gccdos target of the OS/2 makefile (os2/makefile.os2), and for djgpp use the gcc_dos target of the Unix makefile (unix/Makefile). In addition, OS/2 users of MSC can cross-compile to MS-DOS with makefile.os2's mscdos target. (3) If you want a non-standard version of UnZip, define one or more of the following optional macros, either by adding them to the LOCAL_UNZIP environment variable or by editing your makefile as appropriate. The syntax differs from compiler to compiler, but macros are often defined via "-DMACRO_NAME" or similar (for one called MACRO_NAME). Note that some of these may not be fully supported in future releases (or even in the current release). Note also that very short command lines in MS-DOS (128 characters) may place severe limits on how many of these can be used; if need be, the definitions can be placed at the top of unzip.h instead (it is included in all source files). CHECK_EOF (recommended!) Corrupt zipfiles and zipfiles stored on damaged media (e.g., bad floppies) may cause UnZip to go into an infinite loop and either fill the disk(!) or, in some cases (notably under MS-DOS), hang the system. (This only applies to testing or extraction of *damaged* archives, however.) Defining CHECK_EOF enables special code which corrects the problem on most systems; DEC Ultrix may be one excep- tion. The only reason this option is not defined by default is that it was introduced too late in the testing process. DOSWILD (MS-DOS only) Treat trailing "*.*" like Unix "*" (i.e., matches anything); treat trailing "*." as match for files without a dot (i.e., matches any- thing, as long as no dots in name). Special treatment only occurs if patterns are at end of arguments; i.e., "a*.*" matches all files starting with "a", but "*.*c" matches all files ending in "c" *only* if they have a dot somewhere before the "c". Thus "*.*.*" could be used (albeit awkwardly) to specify all filenames with at least one dot in them, and "*." matches all filenames with no dots in them. [The default method of specifying these would be "*.*" and "* -x *.*", respectively, where the second example makes use of UnZip's exclude- files option.] All other regular expressions (including "?" and "[range_of_chars]") retain their Unix-like behavior. VMSWILD (VMS only) Use parentheses rather than brackets to delimit sets (ranges), and use '%' instead of '?' as the single-character wildcard for internal filename matching. (External matching of zipfile names always uses the standard VMS wildcard facilities; character sets are disallowed.) VMSCLI (VMS only) Use VMS-style "slash options" (/FOOBAR) instead of the default Unix- style hyphenated options (-f). This capability was added quite late in the beta cycle and isn't fully tested, so some features may not work as expected. Also, it doesn't affect options stored in environ- ment variables (UNZIP_OPTS or ZIPINFO_OPTS); those use the Unix style regardless. CHECK_VERSIONS (VMS only) UnZip "extra fields" are used to store VMS (RMS) filesystem info, and the format of this information may differ in various versions of VMS. Defining this option will enable UnZip warnings when the stored extra-field VMS version(s) do(es) not match the version of VMS currently being used. This is a common occurrence in zipfiles received from other sites, but since the format of the filesystem does not seem to have changed in years (including on Alpha and Open- VMS systems), the warnings are not enabled by default. RETURN_SEVERITY (VMS only) Return a VMS-style value in the range 0x7fff0001 to 0x7fff0332 for warnings or errors, or 1 for successful completion. See unzip.doc for an explanation of the encoding of the normal UnZip return value. This option was added late in the beta cycle and hasn't been tested much yet, but it will likely become the default in future versions (assuming no collisions with official VMS error codes). RETURN_CODES (VMS only) VMS interprets return codes according to a rigid set of guidelines, which means it misinterprets normal UnZip return codes as all sorts of really nasty errors. Therefore by default VMS UnZip always returns zero regardless of whether any warnings or errors occurred (but see RETURN_SEVERITY above). Define RETURN_CODES for a human-readable ex- planation of UnZip's return codes. Note that this is often annoying. ASM_CRC (Amiga/Aztec C only, for now) Use an assembler routine to calculate the CRC for each file (speed). ASM_INFLATECODES (Amiga/Aztec C only, for now) Use an assembler version of inflate_codes() for speed. OLD_EXDIR (not VMS or TOPS-20) Use old behavior regarding the directory to which to extract: the argument immediately after the zipfile name is the extraction dir; if the directory doesn't exist, create it if it was specified as "dir/" (i.e., with trailing path separator), else treat it as a stored file; if -d is used, treat the argument as a stored file re- gardless of trailing '/'. For example: unzip foo bar if bar is a dir, extract everything into it; otherwise extract bar as stored file unzip foo bar/ extract everything into bar, creating if nec. unzip -d foo bar/ treat bar/ as a stored directory and extract it SFX_EXDIR Enable the "-d <extract_dir>" option for UnZipSFX. By default it is disabled so as to generate the smallest possible executable stub, but for use with automated installation scripts and the like it may be useful to enable -d. Be sure to read unzipsfx.doc for restrictions on the use of this option and of -x; these restrictions should be lifted in a later release. NO_ZIPINFO Compile without zipinfo mode (-Z) enabled; makes a smaller executable because many text strings are left out. Automatically enabled for some small-model compiles under MS-DOS and OS/2, so ordinarily there is no need to specify this explicitly. (Note that even with this defined, the resulting executable may still be too big to extract some zipfiles correctly.) DEBUG Used for debugging purposes; enables Trace() statements. Generally it's best to compile only one or two modules this way. DEBUG_TIME Used for debugging the timezone code in file_io.c; enables TTrace() statements. This code is only used for the freshen/update options (-f and -u), and non-Unix compilers often get it wrong. (4) If you regularly compile new versions of UnZip and always want the same non-standard option(s), you may wish to add it (them) to the LOCAL_UNZIP environment variable (assuming it's supported in your makefile). Under MS-DOS, for example, add this to AUTOEXEC.BAT: set LOCAL_UNZIP -DDOSWILD -DOLD_EXDIR You can also use the variable to hold special compiler options (e.g., -FPi87 for Microsoft C, if the x87 libraries are the only ones on your disk and they follow Microsoft's default naming conventions; MSC also supports the CL environment variable, however). (5) Run the make utility on your chosen makefile: Unix For most systems it's possible to invoke the makefile in place, at the possible cost of an ignorable warning; do "make -f unix/Makefile list" to get a list of possible system targets, and then "make -f unix/Makefile target" for your chosen target. The "generic" target works for most systems, but if it fails with a message about ftime() unresolved or timezone redefined, do "make clean", "make help", and then either "make generic2" or "make generic3" as instructed. If all else fails, read the makefile itself; it contains numerous comments. VMS For a one-time build of the default UnZip, simply run the supplied command file MAKE.COM. To use either DEC C on an Alpha or VAX C on a VAX, type "@make" (after copying make.com into the current direc- tory; otherwise do "@[.vms]make" to invoke it in place). To use GNU C (gcc) on either platform, do "@make gcc". For repeated makes or other hacker-like tinkering with the sources, or to create a custom version of UnZip (especially with VMSCLI), use the included "MMS" makefile, DESCRIP.MMS. Copy it into the current directory, read the comments at the top of it and run MadGoat's free MMS clone "MMK" on it. DEC's MMS is no longer supported due to the use of MMK-specific extensions in DESCRIP.MMS. MS-DOS See the msdos\Contents file for notes regarding which makefile(s) to use with which compiler. In summary: pick one of msdos\makefile.* as appropriate, or (as noted above) use the OS/2 gccdos target for emx+gcc or the Unix gcc_dos target for djgpp. There is also an mscdos cross-compilation target in os2\makefile.os2, an sco_dos cross-compilation target in unix\Makefile and bcc_dos and msc_dos targets in unix\Makefile as well. The latter may disappear soon. For Watcom 16-bit or 32-bit versions, see the comments in the OS/2 section below. After choosing the appropriate makefile and editing as necessary or desired, invoke the corresponding make utility. Microsoft's NMAKE and the free dmake and GNU make utilities are generally the most versatile. Unfortunately, all current ports of GNU make 3.71 (djgpp, emx and gnuish flavors) have bugs which prevent their use with the Unix makefile; the older djgpp port of make 3.69 still works and for now is distributed with the MS-DOS executables on the primary Info- ZIP mirror site (see the Where file). The makefiles in the msdos dir- ectory can be invoked in place (e.g., "nmake -f msdos\makefile.msc"), but the MS-DOS targets in the Unix makefile (gcc_dos, bcc_dos and msc_dos) cannot. OS/2 Either GNU make, nmake or dmake may be used with the OS/2 makefile; all are freely available on the net. Do "nmake -f os2\makefile.os2", for example, to get a list of supported targets. For Watcom C/386 it is necessary to edit makefile.os2 and change the os2$(OBJ) target so it uses backslashes (i.e., "os2/os2.c" -> "os2\os2.c"). For Watcom 16-bit OS/2 versions or any Watcom DOS version (cross-compilation), or for Metaware High C++ (OS/2 32-bit), it is necessary to apply the patch in os2\wat_met.dif. (This patch arrived too late to be fully tested.) More generally, read the comments at the top of the makefile for an explanation of the differences between some of the same-compiler tar- gets. NT (also applies to Chicago/Windows 4) You will need the Windows NT SDK or Visual C++ for NT, both from Microsoft; or DEC C/C++ for DECpc AXP and NT. Use the command line to compile. For the DEC compiler edit out the "cdebug" line in nt\makefile as noted in the comments at the top of the makefile. From the main source directory do "nmake -F nt\makefile". If you are using VC++ you will get warnings about CL386 invoking CL, etc. Don't worry, this is for compatibility with the SDK. Microsoft should have changed the definition of $(cc) in ntwin32.mak for VC++. If you have VC++ 1.5 (16-bit) installed together with VC++ 1.0 (32- bit), make sure that you don't run the 16-bit compiler when you run nmake. At least with MSC 8.x (VC++ 1.x), it is possible to make a dual-mode self-extractor (DOS and NT/Chicago). This is not built by default, but for those who don't care too much about the size, here's how: From: Steve Salisbury <stevesa@microsoft.com> Date: Fri, 22 Jul 94 17:18:06 PDT Did y'all know that you can build a dual mode (MS-DOS and Win32 (NT + Chicago)) unzipsfx.exe by just making a 16-bit unzipsfx.exe and then specifying that as the 16-bit stub for the 32-bit unzip- sfx.exe? You also have to specify the /Knoweas flag to the 16-bit linker. I suspect that this won't work with C 6.0 and earlier, maybe not even with MS C/C++ 7.0. Anyway, I use C 8.0 (a.k.a. Visual C 1.X), which has been shipping for 15+ months now. Make a little change to MSDOS\MAKEFILE.MSC to add the /KNOWEAS flag: LDFLAGS = /KNOWEAS /nologo/noi/e/st:0x0c00 rename the output file ren UNZIPSFX.EXE UNZIPSFX.E16 and then make a little change to NT\MAKEFILE to add the -STUB directive: .obj.exe: $(link) $(ldebug) $(conflags) $(conflibs) $** \ -out:$@ -STUB:$*.e16 This is pretty useful. It's nice to have dual-mode self-extracting files. I do notice that they are pretty huge files (41K for 16-bit unzipsfx.exe, 69k for the 32-bit version, 110k for the dual). Oh well. AmigaDOS SAS/Lattice C and Manx Aztec C are supported. For SAS C 6.x do "lmk -f amiga/SMakeFile all"; for Aztec C do "make -f amiga/makefile.azt all". The Aztec C version supports assembly-language versions of two routines; these are enabled by default. Atari TOS Turbo C is no longer supported; use gcc (tested with 2.4.5 and 2.5.8) and the MiNT libraries, and do "make". Note that all versions of gcc prior to 2.5.8 have a bug affecting 68000-based machines (optimizer adds 68020 instructions). See atari\README for comments on using other compilers. Macintosh Think C is the only currently supported compiler, although the Mac Programmer's Workbench (MPW) was supported at one time and still has hooks in unzip.h. For Think C, un-BinHex the Think C project file and UnZip resource file (using BinHex 4.0 or later), then click on something or other... :-) (I'm just making this up, since I haven't the faintest idea how Mac programming works.) Human68K [This is a Japanese machine and OS.] It appears that GNU make and gcc are required; presumably just do "gmake -f human68k/Makefile.gcc" to build everything. TOPS-20 [No longer fully supported due to new, unported features, although patches always accepted.] Unpack all files into the current directory only (including those in the zipfile's tops20 directory), then use make.mic and "do make". Running the appropriate make utility should produce three executables on most systems, one for UnZip/ZipInfo, one for UnZipSFX, and one for fUnZip. (VMS is one prominent exception: fUnZip makes no sense on it.) Read any OS-specific README files for notes on setting things up for normal use (especially for VMS) and for warnings about known quirks and bugs in var- ious compilers (especially for MS-DOS). Also note that many OSes require a timezone variable to be set correctly (often "TZ"); Unix and VMS generally do so by default, but PC-based OSes generally do not. See the discussion of the -f and -u options in the unzip man page (or unzip.doc). Then test your new UnZip on a few archives and let us know if there are problems (but *please* first make certain that the archives aren't actu- ally corrupted and that you didn't make one of the silly mistakes dis- cussed in the documentation). If possible, test with PKUNZIP or with a previous version of UnZip, if you have one. To install: =========== Unix The default prefix for the installation location is /usr/local (things go into the bin and man/man1 subdirectories beneath the prefix), and the default man-page extension is "1" (corresponding to man/man1, above). To install as per the defaults, do "make install"; otherwise do "make prefix=/your/path manext=your_extension install". For example, to install in your home directory with "l" as the man-page extension (for "local"), do "make prefix=$HOME manext=l install". Permissions will be 755 for the executables and 644 for the man pages. In general root must perform in- stallation into a public directory. Do "rehash" if your shell requires it in order to find the new executables. VMS Install UnZip as foreign symbol by adding this to login.com: $ unzip == "$disk:[dir]unzip.exe" $ zipinfo == "$disk:[dir]unzip.exe ""-Z""" where "disk" and "dir" are the location of the UnZip executable; the "$" before the disk name is important, as are the double-double-quotes around the -Z. Some people, including the author, prefer a short alias such as "ii" instead of "zipinfo"; edit to taste. Optionally also install unzipsfx for use with the MAKESFX.COM command file. See vms/README (or [.VMS]README.) for details on this and for notes/warnings about zipfiles and UnZip under VMS. OS/2, MS-DOS, NT, Atari, Amiga Move or copy unzip.exe (or unzip.ttp, or UnZip, or whatever) to a direc- tory in your path; also possibly copy the UnZip executable to zipinfo.exe (or ii.exe), or else create an alias or a batch or command file for zipinfo ("@unzip -Z %1 %2 %3 %4 %5 %6 %7 %8 %9" under MS-DOS). The latter is only relevant if NO_ZIPINFO was not defined, obviously... Macintosh, Human68K, TOPS-20 Dunno...